REMARKS 

1. Present Status of Patent Application 

This is a full and timely response to the outstanding non-final Office Action of 
August 5, 2008. Claims 1, 10, 19, and 24 have been amended, and claims 1,3-11,13- 
19, 21-25, and 27-32 remain pending in the present application. Reconsideration and 
allowance of the application and presently pending claims are respectfully requested. 

2. Response to Rejections of Claims under 35 U.S.C. §112 

Claims 1, 3-11, 13-19, 21-22, 24-25, and 27-32 have been rejected under 35 
U.S.C. §112, second paragraph. The Office Action alleges that the claim language "local 
presence" is ambiguous and subject to misinterpretation. 

In response, independent claims 1, 10, 19, and 24 have been amended to add 
additionally clarity. Accordingly, withdrawal of the rejections is respectfully requested. 

3. Response to Rejections of Claims under 35 U.S.C. §101 

Claims 1, 3-9, 19, and 21-23 have been rejected under 35 U.S.C. §101 as allegedly 
being directed to non-statutory subject matter. The Office Action contends that the 
claimed subject matter is directed towards a file handling system which is "nothing more 
than software components." 

In response, Applicant submits that the specification states that functional elements 
shown in flowcharts may be implemented by software. The specification does not state 
that a server is implemented by software. Moreover, a "server" may be considered to be 
an "article of manufacture" or a "machine", which are explicitly recognized as statutory 
subject matter under Section 1 01 . For at least these reasons, the rejection of claims 1 , 3- 
9, 19, and 21-23 should be withdrawn. 

Claims 24-25 and 27-32 have been rejected under 35 U.S.C. §101 as allegedly 
being directed to non-statutory subject matter. The Office Action contends that the 
claimed subject matter pertains to a computer-readable storage medium which is defined 
to be a paper storage medium. 

In response, Applicant submits that independent claim 24 recites a "computer 
readable storage medium having a program for handling files on a Connect: Direct server, 
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wherein the computer readable storage medium is a physical structure executed by a 
computer." Further, the specification describes many forms of computer readable 
mediums and does not limit a computer readable medium to being paper. In particular, 
the specification describes that "the computer-readable medium could even be paper or 
another suitable medium upon which the program is printed, as the program can be 
electronically captured, via for instance optical scanning of the paper or other medium, 
then compiled, interpreted or otherwise processed in a suitable manner if necessary, and 
then stored in a computer memory ." Page 12 (Emphasis added). Accordingly, a program 
is described as being stored in computer memory before being executed by a computer, in 
this particular example. For at least these reasons, the language "wherein the computer 
readable storage medium is a physical structure executed by a computer" is not disclosed 
to be paper in Applicant's disclosure. As a result, the rejection of claims 24-25 and 27-32 
should be withdrawn. 

4. Response to Rejections of Claims under 35 U.S.C. $103 

Claims 1, 3-11, 13-19, 21-25, and 27-32 have been rejected under 35 U.S.C. 
§1 03(a) as allegedly being unpatentable over Persels (U.S. Patent No. 7,065,547) in 
view of Hashem (U.S. Patent No. 7,155,578). 

a. Claim 1 

As provided in independent claim 1 , Applicant claims: 
A file handling system, comprising: 

a terminating file transfer server operable to receive a file 
transfer message from an originating file transfer server along with 
at least one file, the file transfer message including details about 
the transfer of said at least one file including a local user and at 
least one filename for said at least one file; 

an agent operable to read the file transfer message 
received from the originating file transfer server, and direct the 
transfer of said at least one filename and said at least one file 
associated with said at least one filename to a home directory 
associated with the local user in accordance with instructions 
from a configuration file residing in the home directory; and 

the configuration file residing in the home directory, and 
operable to instruct the agent to transfer said at least one file 
from the home directory to a remote host, wherein the 
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configuration file comprises a host name and a port name of 
the remote host thereby allowing transfer of said at least one 
file to the remote host without necessitating the remote host 
being logged on the terminating file transfer server. 

(Emphasis added). 

Applicant respectfully submits that independent claim 1 is allowable for at least 
the reason that Persels in view of Hashem does not disclose, teach, or suggest at least 
"an agent operable to read the file transfer message received from the originating file 
transfer server, and direct the transfer of said at least one filename and said at least one 
file associated with said at least one filename to a home directory associated with the 
local user in accordance with instructions from a configuration file residing in the home 
directory; and the configuration file residing in the home directory, and operable to 
instruct the agent to transfer said at least one file from the home directory to a remote 
host, wherein the configuration file comprises a host name and a port name of the 
remote host thereby allowing transfer of said at least one file to the remote host without 
necessitating the remote host being logged on the terminating file transfer server," as 
emphasized above. 

In reviewing the reference, Persels describes that "the eFORWARD Server SM 12 
will invoke an intermediate process specified below. Immediately upon receipt of the 
message by the eFORWARD server SM 12, the eFORWARD server SM 12 determines 
whether the partner eDIRECT™ is 'checked in' (i.e. listening). If so, contact with a 
listening eDIRECT client SM is attempted by sending a short message to the specified IP 
address and listening port. If a destination eDIRECT SM client responds, then the 
message is immediately delivered and so marked in the eFORWARD Server database 
24. If the partner iBox SM eDIRECT client does not respond, then the message is 
retained in the eFORWARD database 24 until the partner iBox SM eDIRECT client 
contacts the eFORWARD Server 12 and requests delivery. An iBox eDIRECT Client is 
considered to be listening if it has sent the eFORWARD Server a message within the 
previous 'n' minutes advising it of the IP address and port number on which it is 
listening . The number of minutes, 'n', is an installation parameter." Col. 6, lines 6-24 
(Emphasis added). 
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Accordingly, Persels requires an eDIRECT client to establish a local presence of 
the client on eFORWARD Server to initiate delivery of a file. As such, Persels does not 
disclose that a configuration file residing in a home directory comprises a host name 
and port name of the remote host where a file is transferred. As a result, Persels fails to 
teach or suggest at least "an agent operable to read the file transfer message received 
from the originating file transfer server, and direct the transfer of said at least one 
filename and said at least one file associated with said at least one filename to a home 
directory associated with the local user in accordance with instructions from a 
configuration file residing in the home directory; and the configuration file residing in the 
home directory, and operable to instruct the agent to transfer said at least one file from 
the home directory to a remote host, wherein the configuration file comprises a host 
name and a port name of the remote host thereby allowing transfer of said at least one 
file to the remote host without necessitating the remote host being logged on the 
terminating file transfer server," as recited in claim 1 . 

Further, Hashem describes techniques for transferring files from a first location to 
a second location. Hashem describes that a file may be placed in an outbasket at a first 
location and a process at the first location transfers the file to an inbasket at a second 
location. See Fig. 5. Hashem describes that an outbasket may correspond to a single 
destination, i.e., an external inbasket. See col. 5, lines 48-50. Hashem further 
describes that a file may be placed in an external inbasket at the second location and a 
process at the first location checks to determine whether a file is found in the external 
inbasket at the second location and downloads the file to the first location if a file is 
found. See Fig. 7. It is noted that a process at the second location does not initiate 
transfer of the file to the first location. Further, Hashem describes that a port parameter 
may be associated with a local basket used to send data in TCP/IP communications. 
Accordingly, this is a port associated with a basket at the basket's location and not a 
port associated with a destination. See col. 12, lines 17-27. 

Thus. Hashem requires a host having an internal inbasket to establish a local 
presence of (e.g.. logging into) the host having the internal inbasket with a host having 
an external outbasket before the host having the internal inbasket can download a file 
from the outbasket of the other host . As such, Hashem individually or in combination 
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with Persels fails to teach or suggest at least "an agent operable to read the file transfer 
message received from the originating file transfer server, and direct the transfer of said 
at least one filename and said at least one file associated with said at least one 
filename to a home directory associated with the local user in accordance with 
instructions from a configuration file residing in the home directory; and the 
configuration file residing in the home directory, and operable to instruct the agent to 
transfer said at least one file from the home directory to a remote host, wherein the 
configuration file comprises a host name and a port name of the remote host thereby 
allowing transfer of said at least one file to the remote host without necessitating the 
remote host being logged on the terminating file transfer server ." as recited in claim 1 . 
For example, neither Persels nor Hashem describes that a file received at an inbasket is 
transferred to a home directory in accordance with instructions by an agent residing at 
the inbasket. For example, Hashem describes that a remote process downloads a file 
found in an external inbasket. 

Accordingly, claim 1 is patentable over Persels in view of Hashem, and the 
rejection of claim 1 should be withdrawn. 

b. Claims 3-9 

For at least the reasons given above, claim 1 is allowable over the cited art of 
record. Since claims 3-9 depend from and include the features of claim 1 and recite 
additional features, claims 3-9 are allowable as a matter of law over the cited art of record. 

c. Claim 10 

As provided in independent claim 10, Applicant claims: 

A method of handling files on a Connect: Direct server, comprising: 

receiving a file transfer message from an originating file transfer 
server at a terminating file transfer server; 

determining a home directory from a local user associated with the 
file transfer message; 

storing at least one file associated with the file transfer message in 
the home directory; 

retrieving a configuration file from the home directory, wherein 
the configuration file comprises a host name and a port name of a 
remote host; and 



12 



transmitting said at least one file responsive to the 
configuration file to the remote host without necessitating the 
remote host being logged on the terminating file transfer server. 

(Emphasis added). 

Applicant respectfully submits that independent claim 10 is allowable for at least 
the reason that Persels in view of Hashem does not disclose, teach, or suggest at least 
"retrieving a configuration file from the home directory, wherein the configuration file 
comprises a host name and a port name of a remote host; and transmitting said at least 
one file responsive to the configuration file to the remote host without necessitating the 
remote host being logged on the terminating file transfer server," as emphasized above. 

In reviewing the reference, Persels describes that "the eFORWARD Server SM 12 
will invoke an intermediate process specified below. Immediately upon receipt of the 
message by the eFORWARD server SM 12, the eFORWARD server SM 12 determines 
whether the partner eDIRECT™ is 'checked in' (i.e. listening). If so, contact with a 
listening eDIRECT client SM is attempted by sending a short message to the specified IP 
address and listening port. If a destination eDIRECT SM client responds, then the 
message is immediately delivered and so marked in the eFORWARD Server database 
24. If the partner iBox SM eDIRECT client does not respond, then the message is 
retained in the eFORWARD database 24 until the partner iBox SM eDIRECT client 
contacts the eFORWARD Server 12 and requests delivery. An iBox eDIRECT Client is 
considered to be listening if it has sent the eFORWARD Server a message within the 
previous 'n' minutes advising it of the IP address and port number on which it is 
listening . The number of minutes, 'n', is an installation parameter." Col. 6, lines 6-24 
(Emphasis added). 

Accordingly, Persels requires an eDIRECT client to establish a local presence of 
the client on eFORWARD Server to initiate delivery of a file. As such, Persels does not 
disclose that a configuration file residing in a home directory comprises a host name 
and port name of the remote host where a file is transferred. As a result, Persels fails to 
teach or suggest at least "retrieving a configuration file from the home directory, wherein 
the configuration file comprises a host name and a port name of a remote host; and 
transmitting said at least one file responsive to the configuration file to the remote host 
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without necessitating the remote host being logged on the terminating file transfer 
server," as recited in claim 10. 

Further, Hashem describes techniques for transferring files from a first location to 
a second location. Hashem describes that a file may be placed in an outbasket at a first 
location and a process at the first location transfers the file to an inbasket at a second 
location. See Fig. 5. Hashem describes that an outbasket may correspond to a single 
destination, i.e., an external inbasket. See col. 5, lines 48-50. Hashem further 
describes that a file may be placed in an external inbasket at the second location and a 
process at the first location checks to determine whether a file is found in the external 
inbasket at the second location and downloads the file to the first location if a file is 
found. See Fig. 7. It is noted that a process at the second location does not initiate 
transfer of the file to the first location. Further, Hashem describes that a port parameter 
may be associated with a local basket used to send data in TCP/IP communications. 
Accordingly, this is a port associated with a basket at the basket's location and not a 
port associated with a destination. See col. 12, lines 17-27. 

Thus, Hashem requires a host having an internal inbasket to establish a local 
presence of the host having the internal inbasket with a host having an external 
outbasket before the host having the internal inbasket can download a file from the 
outbasket of the other host. As such, Hashem individually or in combination with 
Persels fails to teach or suggest at least "retrieving a configuration file from the home 
directory, wherein the configuration file comprises a host name and a port name of a 
remote host; and transmitting said at least one file responsive to the configuration file to 
the remote host without necessitating the remote host being logged on the terminating 
file transfer server," as recited in claim 10. For example, neither Persels nor Hashem 
describes that a file received at an inbasket is transferred to a home directory in 
accordance with instructions by an agent residing at the inbasket. For example, 
Hashem describes that a remote process downloads a file found in an external 
inbasket. 

Accordingly, claim 10 is patentable over Persels in view of Hashem, and the 
rejection of claim 10 should be withdrawn. 
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d. Claims 11 and 13-18 

For at least the reasons given above, claim 10 is allowable over the cited art of 
record. Since claims 1 1 and 13-18 depend from and include the features of claim 10 and 
recite additional features, claims 11 and 13-18 are allowable as a matter of law over the 
cited art of record. 



e. Claim 19 

As provided in independent claim 19, Applicant claims: 

A Connect:Direct file handling system, comprising: 

a terminating file transfer server; 

an agent; and 

a configuration file; 

the terminating file transfer server being operable to launch 
the agent upon receipt of a file transfer message, the file transfer 
message comprising a local username and at least one filename, and 
the agent being operable to direct the transfer of at least one file 
associated with the filename to a home directory associated with the 
username, the agent being further operable to read the configuration 
file, and transfer said at least one file to a remote host specified by 
the configuration file without necessitating the remote host being 
logged on the terminating transfer file server, wherein the 
configuration file is operable to store a host name and a port number 
associated with the remote host. 

(Emphasis added). 

Applicant respectfully submits that independent claim 19 is allowable for at least 
the reason that Persels in view of Hashem does not disclose, teach, or suggest at least 
"the terminating file transfer server being operable to launch the agent upon receipt of a 
file transfer message, the file transfer message comprising a local username and at 
least one filename, and the agent being operable to direct the transfer of at least one file 
associated with the filename to a home directory associated with the username, the 
agent being further operable to read the configuration file, and transfer said at least one 
file to a remote host specified by the configuration file without the remote host being 
logged on the terminating file transfer server, wherein the configuration file is operable 
to store a host name and a port number associated with the remote host," as 
emphasized above. 
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In reviewing the reference, Persels describes that "the eFORWARD Server SM 12 
will invoke an intermediate process specified below. Immediately upon receipt of the 
message by the eFORWARD server SM 12, the eFORWARD server SM 12 determines 
whether the partner eDIRECT™ is 'checked in' (i.e. listening). If so, contact with a 
listening eDIRECT client SM is attempted by sending a short message to the specified IP 
address and listening port. If a destination eDIRECT SM client responds, then the 
message is immediately delivered and so marked in the eFORWARD Server database 
24. If the partner iBox SM eDIRECT client does not respond, then the message is 
retained in the eFORWARD database 24 until the partner iBox SM eDIRECT client 
contacts the eFORWARD Server 12 and requests delivery. An iBox eDIRECT Client is 
considered to be listening if it has sent the eFORWARD Server a message within the 
previous 'n' minutes advising it of the IP address and port number on which it is 
listening. The number of minutes, 'n', is an installation parameter." Col. 6, lines 6-24. 

Accordingly, Persels requires an eDIRECT client to establish a local presence of 
the client on eFORWARD Server to initiate delivery of a file. As such, Persels does not 
disclose that a configuration file residing in a home directory comprises a host name 
and port name of the remote host where a file is transferred. As a result, Persels fails to 
teach or suggest at least "the terminating file transfer server being operable to launch 
the agent upon receipt of a file transfer message, the file transfer message comprising a 
local username and at least one filename, and the agent being operable to direct the 
transfer of at least one file associated with the filename to a home directory associated 
with the username, the agent being further operable to read the configuration file, and 
transfer said at least one file to a remote host specified by the configuration file without 
necessitating the remote host being logged on the terminating file server, wherein the 
configuration file is operable to store a host name and a port number associated with 
the remote host," as recited in claim 19. 

Further, Hashem describes techniques for transferring files from a first location to 
a second location. Hashem describes that a file may be placed in an outbasket at a first 
location and a process at the first location transfers the file to an inbasket at a second 
location. See Fig. 5. Hashem describes that an outbasket may correspond to a single 
destination, i.e., an external inbasket. See col. 5, lines 48-50. Hashem further 
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describes that a file may be placed in an external inbasket at the second location and a 
process at the first location checks to determine whether a file is found in the external 
inbasket at the second location and downloads the file to the first location if a file is 
found. See Fig. 7. It is noted that a process at the second location does not initiate 
transfer of the file to the first location. Further, Hashem describes that a port parameter 
may be associated with a local basket used to send data in TCP/IP communications. 
Accordingly, this is a port associated with a basket at the basket's location and not a 
port associated with a destination. See col. 12, lines 17-27. 

Thus, Hashem requires a host having an internal inbasket to establish a local 
presence of the host having the internal inbasket with a host having an external 
outbasket before the host having the internal inbasket can download a file from the 
outbasket of the other host. As such, Hashem individually or in combination with 
Persels fails to teach or suggest at least "the terminating file transfer server being 
operable to launch the agent upon receipt of a file transfer message, the file transfer 
message comprising a local username and at least one filename, and the agent being 
operable to direct the transfer of at least one file associated with the filename to a home 
directory associated with the username, the agent being further operable to read the 
configuration file, and transfer said at least one file to a remote host specified by the 
configuration file without necessitating the remote host being logged on the terminating 
file server, wherein the configuration file is operable to store a host name and a port 
number associated with the remote host," as recited in claim 19. For example, neither 
Persels nor Hashem describes that a file received at an inbasket is transferred to a 
home directory in accordance with instructions by an agent residing at the inbasket. For 
example, Hashem describes that a remote process downloads a file found in an 
external inbasket. 

Accordingly, claim 19 is patentable over Persels in view of Hashem, and the 
rejection of claim 19 should be withdrawn. 
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f. Claims 21-22 

For at least the reasons given above, claim 1 9 is allowable over the cited art of 
record. Since claims 21-22 depend from and include the features of claim 19 and recite 
additional features, claims 21-22 are allowable as a matter of law over the cited art of 
record. 

g. Claim 23 

Claim 23 has been rejected under 35 U.S.C. §1 03(a) as allegedly being 
unpatentable over Persels in view of Hashem in view of "what was well known in the 
networking art." Applicant respectfully traverses this finding. 

Per MPEP 2144.03(A), "It would not be appropriate for the examiner to take 
official notice of facts without citing a prior art reference where the facts asserted to be 
well known are not capable of instant and unquestionable demonstration as being well- 
known." Also, per MPEP 2144.03(B), "If such notice is taken, the basis for such 
reasoning must be set forth explicitly. The Examiner must provide specific factual 
findings predicated on sound technical and scientific reasoning to support his or her 
conclusion of common knowledge." 

As specific factual findings predicated on sound technical and scientific 
reasoning in support of the conclusion of common knowledge are not provided in the 
Office Action, the rejections based upon this finding should be withdrawn. Further, 
under 37 CFR § 1.104(d)(2), if the rejections are based on facts within the personal 
knowledge of the examiner, "the data should be stated as specifically as possible, and 
the facts must be supported, when called for by the applicant, by an affidavit from the 
examiner. Such an affidavit is subject to contradiction or explanation by the affidavits of 
the applicant and other persons." Therefore, if this rejection is maintained, Applicant 
respectfully requests that document(s) be provided as support. 

Notwithstanding the above traversal, all of the claimed features of independent claim 19 
are not taught and suggested by Persels and Hashem, as previously discussed. Since 
claim 23 depends from claim 1 9 and recites additional features, claim 23 is allowable as a 
matter of law over the cited art. 
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h. Claim 24 



As provided in independent claim 24, Applicant claims: 

A computer readable storage medium having a program for 
handling files on a ConnectDirect server, wherein the computer readable 
storage medium is a physical structure and the program is operable, when 
executed by a computer to perform: 

receiving a file transfer message from an originating file transfer 
server at the terminating file transfer server; 

determining a home directory from a local user associated with the 
file transfer message; 

storing at least one file associated with the file transfer message in 
the home directory; 

retrieving a configuration file from the home directory, wherein 
the configuration file comprises a host name and a port name of a 
remote host; and 

transmitting said at least one file responsive to the 
configuration file to the remote host without necessitating the 
remote host being logged on the terminating file transfer server. 

(Emphasis added). 

Applicant respectfully submits that independent claim 24 is allowable for at least 
the reason that Persels in view of Hashem does not disclose, teach, or suggest at least 
"retrieving a configuration file from the home directory, wherein the configuration file 
comprises a host name and a port name of a remote host; and transmitting said at least 
one file responsive to the configuration file to the remote host without necessitating the 
remote host being logged on the terminating file transfer server," as emphasized above. 

In reviewing the reference, Persels describes that "the eFORWARD Server SM 12 
will invoke an intermediate process specified below. Immediately upon receipt of the 
message by the eFORWARD server SM 12, the eFORWARD server SM 12 determines 
whether the partner eDIRECT™ is 'checked in' (i.e. listening). If so, contact with a 
listening eDIRECT client SM is attempted by sending a short message to the specified IP 
address and listening port. If a destination eDIRECT SM client responds, then the 
message is immediately delivered and so marked in the eFORWARD Server database 
24. If the partner iBox SM eDIRECT client does not respond, then the message is 
retained in the eFORWARD database 24 until the partner iBox SM eDIRECT client 
contacts the eFORWARD Server 12 and requests delivery. An iBox eDIRECT Client is 
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considered to be listening if it has sent the eFORWARD Server a message within the 
previous 'n' minutes advising it of the IP address and port number on which it is 
listening. The number of minutes, 'n', is an installation parameter." Col. 6, lines 6-24. 

Accordingly, Persels requires an eDIRECT client to establish a local presence of 
the client on eFORWARD Server to initiate delivery of a file. As such, Persels does not 
disclose that a configuration file residing in a home directory comprises a host name 
and port name of the remote host where a file is transferred. As a result, Persels fails to 
teach or suggest at least "retrieving a configuration file from the home directory, wherein 
the configuration file comprises a host name and a port name of a remote host; and 
transmitting said at least one file responsive to the configuration file to the remote host 
without necessitating the remote host being logged on the terminating file transfer 
server," as recited in claim 24. 

Further, Hashem describes techniques for transferring files from a first location to 
a second location. Hashem describes that a file may be placed in an outbasket at a first 
location and a process at the first location transfers the file to an inbasket at a second 
location. See Fig. 5. Hashem describes that an outbasket may correspond to a single 
destination, i.e., an external inbasket. See col. 5, lines 48-50. Hashem further 
describes that a file may be placed in an external inbasket at the second location and a 
process at the first location checks to determine whether a file is found in the external 
inbasket at the second location and downloads the file to the first location if a file is 
found. See Fig. 7. It is noted that a process at the second location does not initiate 
transfer of the file to the first location. Further, Hashem describes that a port parameter 
may be associated with a local basket used to send data in TCP/IP communications. 
Accordingly, this is a port associated with a basket at the basket's location and not a 
port associated with a destination. See col. 12, lines 17-27. 

Thus, Hashem describes techniques for transferring files from a first location to a 
second location. Hashem describes that a file may be placed in an outbasket at a first 
location and a process at the first location transfers the file to an inbasket at a second 
location. See Fig. 5. Hashem describes that an outbasket may correspond to a single 
destination, i.e., an external inbasket. See col. 5, lines 48-50. Hashem further 
describes that a file may be placed in an external inbasket at the second location and a 
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process at the first location checks to determine whether a file is found in the external 
inbasket at the second location and downloads the file to the first location if a file is 
found. See Fig. 7. It is noted that a process at the second location does not initiate 
transfer of the file to the first location. Further, Hashem describes that a port parameter 
may be associated with a local basket used to send data in TCP/IP communications. 
Accordingly, this is a port associated with a basket at the basket's location and not a 
port associated with a destination. See col. 12, lines 17-27. 

Accordingly, Hashem requires a host having an internal inbasket to establish a 
local presence of the host having the internal inbasket with a host having an external 
outbasket before the host having the internal inbasket can download a file from the 
outbasket of the other host. As such, Hashem individually or in combination with 
Persels fails to teach or suggest at least "retrieving a configuration file from the home 
directory, wherein the configuration file comprises a host name and a port name of a 
remote host; and transmitting said at least one file responsive to the configuration file to 
the remote host without necessitating the remote host being logged on the terminating 
file transfer server," as recited in claim 24. For example, neither Persels nor Hashem 
describes that a file received at an inbasket is transferred to a home directory in 
accordance with instructions by an agent residing at the inbasket. For example, 
Hashem describes that a remote process downloads a file found in an external 
inbasket. 

Accordingly, claim 24 is patentable over Persels in view of Hashem, and the 
rejection of claim 24 should be withdrawn. 

i. Claims 26-32 

For at least the reasons given above, claim 24 is allowable over the cited art of 
record. Since claims 25 and 27-32 depend from and include the features of claim 24 and 
recite additional features, claims 25 and 27-32 are allowable as a matter of law over the 
cited art of record. 
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CONCLUSION 



Any other statements in the Office Action that are not explicitly addressed herein 
are not intended to be admitted. In addition, any and all findings of inherency are 
traversed as not having been shown to be necessarily present. Furthermore, any and all 
findings of well-known art and official notice, or statements interpreted similarly, should 
not be considered well known for at least the specific and particular reason that the 
Office Action does not include specific factual findings predicated on sound technical 
and scientific reasoning to support such conclusions. 

For at least the reasons set forth above, Applicant respectfully submits that all 
objections and/or rejections have been traversed, rendered moot, and/or 
accommodated, and that the pending claims are in condition for allowance. Favorable 
reconsideration and allowance of the present application and all pending claims are 
hereby courteously requested. In addition, Applicant reserves the right to address any 
comments made in the Office Action that were not specifically addressed herein. Thus, 
such comments should not be deemed admitted by the Applicant. If, in the opinion of 
the Examiner, a telephonic conference would expedite the examination of this matter, the 
Examiner is invited to call the undersigned agent at (770) 933-9500. 



THOMAS, KAYDEN, 
HORSTEMEYER & RISLEY, LLP. 

Suite 1500 

600 Galleria Parkway 
Atlanta, Georgia 30339 
(770) 933-9500 



Respectfully submitted, 
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